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Abstract 


This document defines a framework for the delivery of Internet Media 


Guides (IMGs). An IMG is a structured collection of multimedia 
session descriptions expressed using the Session Description Protocol 
(SDP), SDPng, or some similar session description format. This 


document describes a generalized model for IMG delivery mechanisms, 
the use of existing protocols, and the need for additional work to 
create an IMG delivery infrastructure. 
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Les 


Introduction 


Internet Media Guides (IMGs) provide and deliver structured 
collections of multimedia descriptions expressed using SDP [2], SDPng 
[3], or other description formats. They are used to describe sets of 
multimedia services (e.g., television program schedules, content 
delivery schedules) and refer to other networked resources including 
web pages. IMGs provide an envelope for metadata formats and session 
descriptions defined elsewhere with the aim of facilitating 
structuring, versioning, referencing, distributing, and maintaining 
(caching, updating) such information. 


IMG metadata may be delivered to a potentially large audience, which 
uses it to join a subset of the sessions described and which may need 
to be notified of changes to the IMG metadata. Hence, a framework 
for distributing IMG metadata in various different ways is needed to 
accommodate the needs of different audiences: For traditional 
broadcast-style scenarios, multicast-based (push) distribution of IMG 
metadata needs to be supported. Where no multicast is available, 
unicast-based push is required. 


This document defines a common framework model for IMG delivery 
mechanisms and their deployment in network entities. There are three 
fundamental components in the IMG framework model: data types, 
operation sets, and entities. These components specify a set of 
framework guidelines for efficient delivery and description of IMG 
metadata. The data types give generalized means to deliver and 
manage the consistency of application-specific IMG metadata. IMG 
operations cover broadcast, multicast distribution, event 
notification upon change, unicast-based push, and interactive 
retrievals similar to web pages. 


Since we envision that any Internet host can be a sender and receiver 
of IMG metadata, a host involved in IMG operations performs one or 
more of the roles defined as the entities in the IMG framework model. 
The requirements for IMG delivery mechanisms and descriptions can be 
found in the IMG requirements document [4]. 


This document outlines the use of existing protocols to create an IMG 
delivery infrastructure. It aims to organize existing protocols into 
a common model and show their capabilities and limitations from the 
viewpoint of IMG delivery functions. 


Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [1]. 
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2.1. New Terms 


Internet Media Guide (IMG): IMG is a generic term to describe the 
formation, delivery, and use of IMG metadata. The definition of 
the IMG is intentionally left imprecise [4]. 


IMG Element: The smallest atomic element of metadata that can be 
transmitted separately by IMG operations and referenced 
individually from other IMG elements [4]. 


IMG Metadata: A set of metadata consisting of one or more IMG 
elements. IMG metadata describes the features of multimedia 
content used to enable selection of and access to media sessions 
containing content. For example, metadata may consist of a media 
object's URI, title, airtime, bandwidth needed, file size, text 
summary, genre, and access restrictions [4]. 


IMG Description: A collection of IMG metadata with a data type 
indicating a self-contained set or a subset of IMG metadata, or a 
reference to IMG metadata. 


IMG Delivery: The process of exchanging IMG metadata both in terms of 
large-scale and atomic data transfers [4]. 


IMG Sender: An IMG sender is a logical entity that sends IMG metadata 
to one or more IMG receivers [4]. 


IMG Receiver: An IMG receiver is a logical entity that receives IMG 
metadata from an IMG sender [4]. 


IMG Transceiver: An IMG transceiver combines an IMG receiver and 
sender. It may modify received IMG metadata or merge IMG metadata 
received from a several different IMG senders [4]. 


IMG Operation: An atomic operation of an IMG transport protocol, used 
between IMG sender (s) and IMG receiver (s) for the delivery of IMG 
metadata and for the control of IMG sender (s)/receiver (s) [4]. 


IMG Transport Protocol: A protocol that transports IMG metadata from 
an IMG sender to IMG receiver (s) [4]. 


IMG Transport Session: An association between an IMG sender and one 
or more IMG receivers within the scope of an IMG transport 
protocol. An IMG transport session involves a time-bound series 
of IMG transport protocol interactions that provide delivery of 
IMG metadata from the IMG sender to the IMG receiver (s) [4]. 
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IMG Transfer: A transfer of IMG metadata from an IMG sender to IMG 
receiver(s). 


3. IMG Common Framework Model 


Two common elements are found in all existing IMG candidate cases: 
the need to describe the services and the need to deliver the 
descriptions. In some cases, the descriptions provide multicast 
addresses and thus are part of the transport configuration. In other 
cases, descriptions are specific to the media application and may be 
meant for either human or machine consumption. Thus, the 
technologies can be roughly divided into three areas: 


o Application-specific Metadata: data describing the content of 
services and media which are both specific to certain 
applications and generally human readable. 


o Delivery Descriptions: the descriptions (metadata) that are 
essential to enable (e.g., multicast) delivery. These include 
framing (headers) for application-specific metadata, the 
metadata element identification and structure, and fundamental 
session data. 


o Delivery Protocols: the methods and protocols to exchange 
descriptions between the senders and the receivers. An IMG 
transport protocol consists of two functions: carrying IMG 
metadata from an IMG sender to an IMG receiver and controlling 
an IMG transport protocol. These functions are not always 
exclusive; therefore, some messages may combine control messages 
and metadata carriage functions to reduce the amount of the 
messaging. 


3.1. IMG Data Types 


A data model is needed to precisely define the terminology and 
relationships between sets, supersets, and subsets of metadata. A 
precise data model is essential for the implementation of IMGs, 
although it is not within the scope of this framework and requires a 
separate specification. However, there are three IMG data types in 
general: Complete IMG Descriptions, Delta IMG Descriptions, and IMG 
Pointers. 


3.1.1. Complete IMG Description 


A Complete IMG Description provides a self-contained set of metadata 
for one media object or service, i.e., it does not need additional 
information from any other IMG element. This is not to be confused 
with "complete IMG metadata", which, although vaguely defined here, 
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represents the complete IMG metadata database of an IMG sender (or 
related group of IMG senders -- potentially the complete Internet IMG 
knowledge). An IMG sender will generally deliver only subsets of 
metadata from its complete database in a particular IMG transport 
session. 


3.1.2. Delta IMG Description 


A Delta IMG Description provides only part of a Complete IMG 
Description, defining the difference from a previous version of the 
Complete IMG Description. Delta IMG Descriptions may be used to 
reduce network resource usage, for instance, when data consistency is 
essential and small and frequent changes occur to IMG elements. 

Thus, this description does not represent a complete set of metadata 
until it is combined with other metadata that may already exist or 
arrive in the future. 


3.1.3. IMG Pointer 


An IMG Pointer identifies or locates metadata. This may be used to 
separately obtain metadata (Complete or Delta IMG Descriptions) or 
perform another IMG management function such as data expiry (and 
erasure). The IMG Pointer may be used to reference IMG metadata 
elements within the IMG transport session and across IMG transport 
sessions. This pointer type does not include IMG metadata per se 
(although it may also appear as a data field in Complete or Delta IMG 
Descriptions). 


3.2. IMG Entities 
There are several fundamental IMG entities that indicate the 
capability to perform certain roles. An Internet host involved in 
IMG operations may adopt one or more of these roles, which are 


defined in more detail in Section 3.3. 


IMG Announcer: sends IMG ANNOUNCE 


IMG Listener: receives IMG ANNOUNCE 
IMG Querier: sends IMG QUERY and receives IMG RESOLVE 
IMG Resolver: receives IMG QUERY then sends IMG RESOLVE 


IMG Subscriber: sends IMG SUBSCRIBE then receives IMG NOTIFY 


IMG Notifier: receives IMG SUBSCRIBE then sends IMG NOTIFY 
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Figure 1 shows the relationship between IMG entities and the IMG 


sender and receiver. 


$ aa - - 5 + 
| IMG Sender | 
4+------------------ 4+------------------ 4+------------------ + 
| IMG Announcer IMG Notifier IMG Resolver | 
4+------------------ 4+------------------ 4+------------------ + 
message | | 
direction v v v 
+------------------ 4+------------------ 4+------------------ + 
| IMG Listener IMG Subscriber | IMG Querier | 
4+------------------ 4+------------------ 4+------------------ + 
| IMG Receiver | 
4+------------------ 4+------------------ 4+------------------ + 
Figure 1: Relationship between IMG Entities, Senders, and Receivers 
3.3. Operation Set for IMG Delivery 
A finite set of operations both meets the IMG requirements [4] and 
fits the roles of existing protocols. These are crystallized in the 
next few sections. 
32:34 2 IMG ANNOUNCE 
When an IMG receiver participates in unidirectional communications 
(e.g., over satellite, terrestrial radio, and wired multicast 
networks), an IMG receiver may not need to send any IMG message to an 
IMG sender prior to IMG metadata delivery. In this case, an IMG 


sender can initiate unsolicited distribution for IMG metadata and an 


IMG sender is the only entity that can maintain the 


distribution 


(this includes scenarios with multiple and cooperative IMG senders). 
This operation is useful when there are large numbers of IMG 
receivers or the IMG receivers do not have a guaranteed uplink 


connection to the IMG sender. 


The IMG sender may also include 


authentication data in the ANNOUNCE operation so that IMG receivers 


may check the authenticity of the metadata. 
any of the IMG data types. 


This operation can carry 


There is no restriction to prevent IMG ANNOUNCE from being used in an 


asynchronous solicited manner, 
out of band) 
ANNOUNCE operation. 
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enables IMG receivers to subscribe/register to the IMG 


(possibly 
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3.3.2. IMG QUERY 


If an IMG receiver needs to obtain IMG metadata, an IMG receiver can 
use an IMG QUERY operation and initiate a receiver-driven IMG 
transport session. The IMG receiver expects a synchronous response 
to the subsequent request from the IMG sender. This operation can be 
used where a bidirectional transport network is available between the 
IMG sender and receiver. Some IMG receivers may want to obtain IMG 
metadata when network connectivity is available or just to avoid 
caching unsolicited IMG metadata. The IMG receiver must indicate the 
extent and data type of metadata wanted in some message in the 
operation. The extent indicates the number and grouping of metadata 
descriptions. In some cases, it may be feasible to request an IMG 
sender’s complete metadata collection. 


3.3.3. IMG RESOLVE 


An IMG sender synchronously responds, and sends IMG metadata, to an 
IMG QUERY that has been sent by an IMG receiver. This operation can 
be used where a bidirectional transport network is available between 
the IMG sender and receiver. If the IMG QUERY specifies a subset of 
IMG metadata (extent and data type) that is available to the IMG 
sender, the IMG sender can resolve the query; otherwise, it should 
indicate that it is not able to resolve the query. The IMG sender 
may authenticate the IMG receiver during the QUERY operation to 
determine if the IMG receiver is authorized to receive that metadata. 
The sender may also include authentication data in the RESOLVE 
operation so that IMG receivers may check the authenticity of the 
metadata. This operation may carry any of the IMG data types. 


3.3.4. IMG SUBSCRIBE 


If an IMG receiver wants to be notified when the IMG metadata it 
holds becomes stale, the IMG receiver can use the IMG SUBSCRIBE 
operation in advance in order to solicit IMG NOTIFY messages from an 
IMG sender. 


This operation may provide the IMG sender with specific details of 
which metadata or notification services it is interested in the case 
where the IMG sender offers more than the simplest "all data" 


service. This operation implicitly provides the functionality of 
unsubscribing to inform an IMG sender that an IMG receiver wishes to 
stop getting certain (or all) notifications. It should be noted that 


unsubscription may be provided implicitly by the expiry (timeout) of 
a subscription before it is renewed. 
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Since the IMG receiver does not know when metadata will be updated 
and the notify message will arrive, this operation does not 
synchronize with the notify messages. The IMG receiver may wait for 
notify messages for a long time. The IMG sender may authenticate the 
IMG receiver to check whether an IMG SUBSCRIBE operation is from an 
authorized IMG receiver. 


3.3.5. IMG NOTIFY 


An IMG NOTIFY is used asynchronously in response to an earlier IMG 
SUBSCRIBE. An IMG NOTIFY operation indicates that updated IMG 
metadata is available or part of the existing IMG metadata is stale. 
An IMG NOTIFY may be delivered more than once during the time an IMG 
SUBSCRIBE is active. This operation may carry any of the IMG data 
types. The IMG sender may also include authentication data in the 
IMG NOTIFY operation so that IMG receivers may check the authenticity 
of the messages. 


3.3.6. Binding between IMG Operations and Data Types 


There is a need to provide a binding between the various IMG 
operations and IMG data types to allow management of each discrete 
set of IMG metadata transferred using an IMG operation. This binding 
must be independent of any particular metadata syntax used to 
represent a set of IMG metadata, as well as be compatible with any 
IMG transport protocol. The binding must uniquely identify the set 
of IMG metadata delivered within an IMG transfer, regardless of the 
metadata syntax used. The uniqueness may only be needed within the 
domains the metadata is used, but this must enable globally unique 
identification to support Internet usage. Care should be taken that 
scope- and domain-specific identifiers do not leak outside the scope; 
using globally unique identifiers such as URLs avoids these problems. 


The binding must provide versioning to the transferred IMG metadata 
so that changes can be easily handled and stale data identified, and 
give temporal validity of the transferred IMG metadata. It must 
invalidate the IMG metadata by indicating an expiry time, and may 
optionally provide a time (presumably in the future) from when the 
IMG metadata becomes valid. The temporal validity of a metadata 
object may need to be updated later. Furthermore, the binding must 
be independent of any specific metadata syntax used for the IMG 
metadata, in the sense that no useful syntax should be excluded. 
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4. 


4. 
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Overview of Protocol Operations 


Figure 2 gives an overview of the relationship between transport 
cases, IMG operations, and IMG data types. It is not a protocol 
stack. Generalized multicast point-to-multipoint (P-to-M) and 
unicast point-to-point (P-to-P) transports are shown. 


IMG 
Data Types 


Complete Desc., Delta Desc., Pointer 


+---------------- 4+------------- + 
IMG | IMG ANNOUNCE | IMG SUBSCRIBE | IMG QUERY 
Operations | | IMG NOTIFY | IMG RESOLVE | 
4+-------------- 4+----+---------------- 4+------------- + 
IMG 
Transport P-to-M | P-to-P 
4+-------------- $ oo + 


Figure 2: IMG Transport, IMG Operations, and IMG Data Types 
Deployment Scenarios for IMG Entities 


This section provides some basic deployment scenarios for IMG 


entities that illustrate common threads from protocols to use cases. 


For the purposes of clarity, this document presents the simple 


dataflow from an IMG sender to an IMG receiver, as shown in Figure 3. 


Figure 3: A Simple IMG Sender to IMG Receiver Relationship 


1. Intermediary Cases 


Some IMG metadata may be distributed to a large number of IMG 


receivers, for example, when public metadata is distributed to all 
IMG receivers of a certain group. This kind of IMG metadata may be 
distributed from one IMG sender to multiple IMG receivers (Figure 4) 
or may be relayed across a set of IMG transceivers that receive the 
IMG metadata, possibly filter or modify its content, and then forward 


Ita 
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+---------- + Ho + 
| IMG | | IMG | 
| Sender  |---- ---->| Receiver | 
+---------- + \ / Ho + 
\ / 
\ Ho EE E E + / 
-->| IMG |----- 
-->| Transceiver | \ 
/ do + \ 
Ho ses + / \ aana + 
| IMG | / ---->| IMG | 
| Sender  |---- | Receiver | 
+---------- + Ho + 


Figure 4: A Relay Network with an IMG Transceiver 


IMG senders and receivers are logical functions, and it is possible 
for some or all hosts in a system to perform both roles, as, for 
instance, in many-to-many communications or where a transceiver is 
used to combine or aggregate IMG metadata for some IMG receivers. An 
IMG receiver may be allowed to receive IMG metadata from any number 
of IMG senders. 


IMG metadata is used to find, obtain, manage, and play media content. 
IMG metadata may be modified during IMG transfer. For example, a 
server may use IMGs to retrieve media content via unicast and then 
make it available at scheduled times via multicast, thus requiring a 
change of the corresponding metadata. IMG transceivers may add or 
delete information or aggregate IMG metadata from different IMG 
senders. For example, a rating service may add its own content 
ratings or recommendations to existing metadata. An implication of 
changing (or aggregating) IMG metadata from one or more IMG senders 
is that the original authenticity is lost. Thus, it may be 
beneficial to sign fragments so that the intermediary can replace a 
fragment without changing the authenticity of the remainder. For 
example, smaller fragments may be appropriate for more volatile 
parts, and larger ones may be appropriate for stable parts. 
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4.2. One-to-Many Unidirectional Multicast 


The one-to-many unidirectional multicast case implies many IMG 
receivers and one or more IMG senders implementing IMG announcer and 
IMG listener operations as shown in Figure 5. 


Unidirectional HE + 
--------------- > | IMG | 
downlink Listener 
------------- > il 
/ 4====>===5= + 
prerane + / 
| IMG | -------- 
| Announcer | \ 
Aa WA + \ S E + 
------------- > IMG 
Listener 
aa | 
Ho + 


Figure 5: IMG Unidirectional Multicast Distribution Example 


Note, as defined in the IMG requirement REL-4 [4], an IMG transport 
protocol MUST support reliable message exchange. This includes the 
one-to-many unidirectional multicast case; however, the mechanism to 
provide this is beyond the scope of this document. 


4.3. One-to-One Bidirectional Unicast 
In the one-to-one bidirectional unicast case, both query/resolve 


(Figure 6) and subscribe/notify (Figure 7) message exchange 
operations are feasible. 


4---------- + 4+---------- + 
| IMG | omo | 
| Resolver | | Querier | 
t---------- + #t---------- + 
| | 
| <---------- IMG QUERY ----------- | 
---------- IMG RESOLVE----------> 


Figure 6: Query/Resolve Sequence Example 
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4+---------- + 4+------------ + 
| IMG | | IMG | 
| Notifier | | Subscriber | 
4+---------- + 4+------------ + 
| | 
| <--------- IMG SUBSCRIBE--------- 


Figure 7: Subscribe/Notify Sequence Example 
4.4. Combined Operations with Common Metadata 
As shown in Figure 8, a common data model for multiple protocol 


operations allows a diverse range of IMG senders and receivers to 
provide consistent and interoperable sets of IMG metadata. 


IMG Metadata IMG Senders IMG Receivers 
oo 222 + 
ARSS + =--->| IMG Listener | 
| IMG | / t-------------- + 
/| Announcer |----- 
+------------- + [{ Ho Re + \ $ eS EnS + 
| IMG |-+ / ---->| IMG Listener | 
| description | |-+ / [Lara | 
| metadata 1 | / he ae O + /--->| IMG Querier | 
+------------- + | | ----- | IMG |<----/ +-------------- + 
poene 2 7 + | \ | Resolver | 
$ a ON i E E +<----\ A S + 
\ \--->| IMG Querier | 
\ +----------- + | ------- | 
\| IMG <--------- >| IMG 
Notifier Subscriber 
Ho + do + 


Figure 8: Combined System with Common Metadata 
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5. Applicability of Existing Protocols to the Proposed Framework Model 
5.1. Existing Standards Fitting the IMG Framework Model 


SDP: The SDP format [2] could be used to describe session-level 
parameters (e.g., scheduling, addressing, and the use of media 
codecs) to be included in Complete IMG Descriptions. Although there 
are extension points in SDP allowing the format to be extended, there 
are limitations in the flexibility of this extension mechanism. 
However, SDP syntax cannot provide IMG Descriptions and IMG Pointers 
without significant overhead. It is expected that the information 
conveyed by SDP is just a small subset of IMG metadata; thus, the use 
of SDP for other than session parameters may not be reasonable. 


SDPng [3]: Similar to SDP, this format could also be used for 
representing session-level parameters of IMG metadata. Compared to 
SDP, the XML-based format of SDPng should be much more flexible and 
allow extensions and integration with other description formats. 


MPEG-7: Descriptions based on the MPEG-7 standard [5] could provide 
application-specific metadata describing the properties of multimedia 
content beyond parameters carried in SDP or SDPng descriptions. 
MPEG-7 provides a machine-readable format of representing content 
categories and attributes, helping end-users or receiving software in 
choosing content for reception. MPEG-7 is based on XML, so it is 
well suited to be combined with other XML-based formats such as 
SDPng. 


TV-Anytime: The TV-Anytime Forum [6] provides descriptions based on 
XML schema for TV-specific program guides. TV-Anytime uses the 
MPEG-7 User description profile to a limited extent, only for user 
preferences and usage history, and also a TV-Anytime-specific data 
model for other schema. These are optimized to describe broadcast 
schedules, on-demand program guides and program events. 


HTTP: The HTTP protocol [7] can be used as a bidirectional unicast 
IMG transport protocol. Being a request-reply-oriented protocol, 
HTTP is well suited for implementing synchronous operations such as 
QUERY, RESOLVE, and even SUBSCRIBE. However, HTTP does not provide 
asynchronous operations such as ANNOUNCE and NOTIFY and to implement 
asynchronous operations using HTTP, IMG receivers should poll the IMG 
sender periodically. Thus, by itself, HTTP is not sufficient to 
fulfill all of the IMG requirements [4] in a unicast deployment. 


Session Announcement Protocol (SAP): The announcement mechanism 
provided by SAP [8] provides unidirectional delivery of session 
discovery information. Although SDP is the default payload format of 
SAP, the use of a MIME type identifier for the payload allows 
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arbitrary payload formats to be used in SAP messages. Thus, SAP 
could be used to implement the multicast and unicast IMG ANNOUNCE and 
IMG NOTIFY operations. 


However, SAP lacks scalable and efficient reliability, extensibility 
for payload size, and congestion control, and only one description is 
allowed per SAP message due to lack of payload segmentation. 


In principle, SAP could be extended to get around its limitations. 
However, the amount of changes needed in SAP to address all of the 


above limitations would effectively result in a new protocol. Due to 
these limitations, the use of SAP as an IMG transport protocol is not 
recommended. 


SIP: The SIP-specific event mechanism described in RFC 3265 [9] 
provides a way to implement IMG SUBSCRIBE and IMG NOTIFY operations 
via a bidirectional unicast connection. However, there are 
scalability problems with this approach, as RFC 3265 currently does 
not consider multicast. 


Real Time Streaming Protocol (RTSP): The RTSP protocol [10] defines a 
retrieval-and-update notification mechanism, named DESCRIBE and 
ANNOUNCE, for the description of a presentation or media object in 
order to initialize a streaming session. These methods are a subset 
of the entire streaming control operations in RTSP; thus, these could 
not be available for individual mechanisms. However, the DESCRIBE 
method in RTSP could be used to instantiate IMG QUERY, IMG RESOLVE, 
and IMG SUBSCRIBE, and the RTSP ANNOUNCE could be used to instantiate 
an IMG NOTIFY for a streaming session controlled by RTSP. 


5.2. IMG Mechanism Needs Which Are Not Met by Existing Standards 


Several needs result from the IMG requirements, framework model, and 
existing relevant mechanisms as already shown in this document. Four 
specific groupings of work are readily apparent: (a) specification of 
an adequate multicast- and unidirectional-capable announcement 
protocol; (b) specification of the use of existing unicast protocols 
to enable unicast subscribe and announcement/notification 
functionality; (c) specification of the metadata envelope that is 
common to, and independent of, the application metadata syntax (es) 
used; and (d) agreement on basic metadata models to enable 
interoperability testing of the above. The following sections 
describe each of these. 
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5.2.1. A Multicast Transport Protocol 


SAP is currently the only open standard protocol suited to the 
unidirectional/multicast delivery of IMG metadata. As discussed, it 
fails to meet the IMG requirements in many ways and, since it is not 
designed to be extensible, we recognize that a new multicast 
transport protocol for announcements needs to be specified to meet 
IMG needs. This protocol will be essential to IMG delivery for 
unidirectional and multicast deployments. 


The Asynchronous Layered Coding (ALC) [11] protocol from the IETF 
Reliable Multicast Transport (RMT) working group is very interesting 
as it fulfills many of the requirements, is extensible, and has the 
ability to 'plug-in” both FEC (Forward Error Correction, for 
reliability) and CC (Congestion Control) functional blocks. It is 
specifically designed for unidirectional multicast object transport. 
ALC is not fully specified, although the RMT working group had a 
fully specified protocol using ALC called FLUTE (File Delivery over 
Unidirectional Transport) [12]. FLUTE seems to be the only fully 
specified transport and open specification on which a new IMG 
announcement protocol could be designed. Thus, we recommend that ALC 
and FLUTE be the starting points for this protocol’s design. 


Developing a new protocol from scratch, or attempting to improve SAP, 
is also feasible, although it would involve repeating many of the 
design processes and decisions already made by the IETF for ALC. In 
particular, any announcement protocol must feature sufficient 
scalability, flexibility, and reliability to meet IMG needs. Also, 
the IMG ANNOUNCE operation must be supported and IMG NOTIFY 
capability could be investigated for both hybrid unicast-multicast 
and unidirectional unicast systems. 


5.2.2. Usage of Unicast Transport Protocols 


A thorough description of the use of existing unicast protocols is 
essential for the use of IMGs in a unicast point-to-point 
environment. Such a specification has not been published, although 
several usable unicast transport protocols and specifications can be 
harnessed for this (SIP [13], SIP events [9], HTTP [7], etc.). In 
particular, both IMG SUBSCRIBE-NOTIFY and IMG QUERY-RESOLVE operation 
pairs must be enabled. We anticipate that the IMG QUERY-RESOLVE 
operation can be achieved using HTTP, although other transport 
protocol options may be beneficial to consider too. 
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5.2.3. IMG Envelope 


An IMG envelope provides the binding between IMG operations and data 
types. Such a binding can be realized by defining a common minimal 
set of information needed to manage IMG metadata transfers, and by 
including this information with any set of IMG metadata delivered to 
IMG receivers. 


Four options for IMG metadata transfer envelope delivery are 
feasible: 


1. Embedding in a transport protocol header. This can be done 
with either header extensions of existing protocols, or newly 
defined header fields of a new (or new version of a) transport 
protocol. However, multiple methods for the variety of 
transport protocols would hinder interoperability and 
transport protocol independence. 


2. A separate envelope object, which points to the IMG metadata 
‘object’, delivered in-band with the metadata transport 
protocol session. This might complicate delivery as the 
envelope and ’service’ metadata objects would have to be 
bound, e.g., by pairing some kind of transport object numbers 
(analogous to port number pairs sometimes used for RTP and 
RTCP [14]). This would also enable schemes that deliver 
envelope and metadata 'objects” by different media, also using 
more than a single transport protocol. 


3. A metadata wrapper that points to and/or embeds the service 
metadata into its ’super-syntax’. For example, XML would 
enable embedding generic text objects. 


4. Embedding in the metadata itself. However, this requires a 
new field in many metadata syntaxes and would not be feasible 
if a useful syntax were not capable of extensibility in this 
way. It also introduces a larger 'implementation 
interpretation’ variety, which would hinder interoperability. 
Thus, this option is not recommended. 


It is likely that more than one of these options will fulfill the 
needs of IMGs, so the selection, and possibly optimization, is left 
for subsequent specification and feedback from implementation 
experience. Such a specification is essential for IMG delivery. 


When there are superset/subset relations between IMG Descriptions, it 
is assumed that the IMG Descriptions of the subset inherit the 
parameters of the superset. Thus, an IMG metadata transfer envelope 
carrying the IMG Descriptions of a superset may implicitly define 
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parameters of IMG Descriptions belonging to its subset. The 
relations between IMG Descriptions may span from one envelope to 
another according to a data model definition. 


5.2.4. Metadata Data Model 


A structured data model would allow reuse and extension of the set of 
metadata and may enable use of multiple syntazes (SDP, MPEG-7, etc.) 
as part of the same body of IMG metadata. 


For the successful deployment of IMGs in various environments, 
further work may be needed to define metadata and data models for 
application-specific requirements. Existing (and future) work on 
these would need to be mapped to the IMG data types and use of the 
IMG transfer envelope concept as described above. 


This document is a framework for the delivery of IMG metadata and 
thus further discussion on the definition data models for IMGs is 
beyond its scope. 


6. Security Considerations 


The IMG framework is developed from the IMG requirements document 
[4], and so the selection of specific protocols and mechanism for use 
with the IMG framework must also take into account the security 
considerations of the IMG requirements document. This framework 
document does not mandate the use of specific protocols. However, an 
IMG specification would inherit the security considerations of 
specific protocols used. 


Protocol instantiations that are used to provide IMG operations will 
have very different security considerations depending on their scope 
and purpose. However, there are several general issues that are 
valuable to consider and, in some cases, provide technical solutions 
for. These are described below. 


Individual and group privacy: Customized IMG metadata may reveal 
information about the habits and preferences of a user and may thus 
deserve confidentiality protection, even if the original information 
were public. Protecting this metadata against snooping requires the 
same actions and measures as for other point-to-point and multicast 
Internet communications. Naturally, the risk of snooping depends on 
the amount of individual or group personalization the IMG metadata 
contains. 


IMG authenticity: In some cases, the IMG receiver needs to be assured 


of the sender or origin of IMG metadata or its modification history. 
This can prevent denial-of-service or hijacking attempts that give an 
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IMG receiver incorrect information in or about the metadata, thus 
preventing successful access of the media or directing the IMG 
receiver to the incorrect media possibly with tasteless material. 


IMG receiver authorization: Some or all of any IMG sender's metadata 
may be private or valuable enough to allow access to only certain IMG 
receivers and thus make it worth authenticating users. Encrypting 
the data is also a reasonable step, especially where group 
communications methods results in unavoidable snooping opportunities 
for unauthorized nodes. 


Unidirectional specifics: A difficulty that is faced by 
unidirectional delivery operations is that many protocols providing 
application-level security are based on bidirectional communications. 
The application of these security protocols in case of strictly 
unidirectional links is not considered in the present document. 


Malicious code: Currently, IMGs are not envisaged to deliver 
executable code at any stage. However, as some IMG transport 
protocols may be capable of delivering arbitrary files, it is 
RECOMMENDED that the IMG operations do not have write access to the 
system or any other critical areas. 
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